With the proliferation of software products and services, attempts have been made to codify and/or standardize the designing of software and software architecture. Examples include:
The Booch Method and Modeling Language (see “Object Oriented Analysis and Design” by Grady Booch);
James Rumbaugh and associates' Object Modeling Technique (OMT);
the Object Oriented Software Engineering (OOSE) method by Ivar Jacobson; and
the Unified Modeling Language (UML) which combines the foregoing and industry best practices.
The UML is a visual modeling language (with formal syntax and semantics) for communicating a model or conceptionalization. Thus the modeling language specification specifies modeling elements, notation and usage guidelines and not order of activities, specification of artifacts, repository interface, storage, run-time behavior and so forth. In general, at the modeling level a “problem” is posed in terms of a customer's needs and requirements and may be referred to as the business problem system. The software designer develops a “solution” software product and or service that addresses the problem. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner, while the UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase. See “UML in a Nutshell” by Simon Si Alhir, published by O'Reilly & Associates, September 1998. As such, the UML enables the sharing of information (including prior solution portions) and extension (without reimplementation) of core object oriented concepts (analysis and design) during the iterative problem-solving process for designing software products.
In UML 2.0, properties and operations can be redefined (in the context of generalization) with, for example, a different type and/or multiplicity that is consistent with the original. The redefined property commonly has the same name as the property it is redefining, but this is not always the case. Redefinition is indicated using a redefines constraint, which is typically left out if the name remains the same.
The Rose model for UML 2.0 contains many properties whose names, types, and/or multiplicities have been redefined. There are, however, no known mechanisms for generating Java code that enforces these constraints. The Eclipse Modeling Framework (EMF) can be used to generate Java code from a Rose model, but provides no automated support for processing redefinitions.
One aspect of EMF (and of the Java language) that affects the treatment of redefined properties is the way multiple inheritance is handled. When processing a class that is defined to have more than one superclass, EMF will generate an interface that extends all of the interfaces corresponding to the specified superclasses, but the implementation class will extend only one of the implementation classes (since multiple inheritance is illegal in Java). The class that is extended by the implementation class is referred to as the class's primary superclass; all other superclasses are referred to as secondary, or mixin, superclasses.
Properties whose names are redefined do not pose a problem as far as EMF is concerned since it considers the redefined and redefining properties as separate properties. However, this means that the generated code will not indicate in any way that the redefining property in fact overrides the redefined property. It would be desirable for the generated code to in some way reflect the redefinition, and for the data in these properties to be serialized only once.
All other redefined aspects of properties pose problems to EMF. This is because properties with the same name are considered duplicates by EMF, and are factored out of the Ecore model (i.e., of the UML2 metamodel) during validation.